The present invention relates generally to architectures for software installation and specifically to architectures for diagnosing problems caused by software installation.
Software on product installations are not only complex but can create a host of systemic problems, particularly for xe2x80x9cWINDOWSxe2x80x9d operating systems. These problems can cause the newly installed and/or previously installed software on a target computer to fail.
Reasons for such failures are many. Typically, there are a variety of system or shared files that the new software may utilize. During installation, a different version (i.e., a newer or older version) of such system and/or shared files may overwrite or replace one or more existing system and/or shared files. The newly installed files may be incompatible with existing files. Alternatively, a system and/or shared file that is not replaced during installation may be incompatible with the installed software. For example, it is not uncommon for a user to modify an existing file, particularly when the file is part of software originally distributed as source code (e.g., a web page).
The reasons for the failure are often difficult to diagnose. First, diagnosis typically requires a broad range of information about the target computer that is currently gathered by not one but a number of different tools. These tools are often difficult to use and/or do not interface with one another. Second, where several versions of a file exist on the system it may not be possible to determine which of these files is being utilized by the software. In xe2x80x9cWINDOWSxe2x80x9d applications, for example, a System Registry (which stores setup information for the hardware, software and operating system) is used to locate system or shared files. Only one version of a specific file can be registered, though multiple versions of that file may exist on the system. The version that is being used by an application may not be the one that is listed in the Registry. Third, the database required to perform the diagnosis can be large, cumbersome, and as a result laden with errors. Existing products for diagnosing software failures, such as xe2x80x9cVERSION STAMPERxe2x80x9d by Desaware and a program known as MMDebug.EXE in the Lucent xe2x80x9cINTUITYxe2x80x9d message manager of Lucent Technologies Inc., require a manually generated database of known files that is compared to the files on the target computer. In some applications, the number of files, registry entries, and other information to be compared and/or gathered during diagnosis can be large (e.g., thousands of items). Finally, an end user modification of a file used by the installed software can be extremely difficult to detect particularly when the person performing the diagnosis is unaware that the end user performed any modifications to the system.
The method and system of the present invention addresses these and other problems of the prior art. Briefly, the method and system automatically generates an installation file or database containing information describing or characterizing the installation. A verification tool can compare the installation information to installed information relating to or describing the files actually installed by the install program to locate or identify potential problems. As will be appreciated, an install program or software is a means or algorithm by which a program and its supporting files and other information can be placed onto a target computer in a predetermined fashion. Some user input is generally required to properly configure the software before or during installation.
In a first embodiment, a method for generating information for use in verifying an installation of software onto a target computer includes:
(a) parsing the script (e.g., a file containing commands to be executed) of install software to provide a list of items (e.g. files) regarding the install software; and
(b) collecting information about each item in the list to form installation data. To verify the installation, the method can include additional steps such as executing the install software on a target computer and comparing the installation data with information on the target computer. In one configuration, the method includes the additional step of incorporating the installation data from the second step into the installation program such that the installation is installed in the executing step.
As will be appreciated, xe2x80x9cparsingxe2x80x9d refers to the analysis by a computer of the structure of statements in a human or artificial language. Parsing is typically done by comparing text to be parsed with a grammar which defines possible structures. The parsing can be done top-down (i.e., the computer starts by looking for a particular constituent) or bottom-up (i.e., the computer accepts elements from the text and tries to put them together).
The information in the installation data can include one or more of the following: file description, file location, file size, file version, last modification date of file, and whether or not the file is registered and where in the Registry the file is registered. The information can be combined with additional input that is customized for a specific application. Such additional information could include file grouping and override default error analysis/reporting performed by the comparing step. The information can be in a format that is not easily editable by an end-user to assist in the detection of end-user modifications of application files. This prevents the end-user from easily concealing such modifications.
This embodiment of the present invention has many advantages over the prior art including automated gathering of file and registry information, the use of installation script as a source for file and registry information, and/or viewing of remotely saved and/or transmitted data and of file contents, directories, system parameters, and arbitrary system registry entries.
The parsing step can include a number of substeps. For example, parsing can include the substep of setting a mode indicator for controlling a mode of the computer. The mode is typically a parsing mode and/or a nonparsing mode. The parsing step can further include the step of searching in the text of the script for a symbol (e.g., a compiler variable and/or a noncompiler variable) indicating a change in the mode of the computer. In this regard, the computer may determine a nesting level associated with a compiler variable and set the mode indicator based on the nesting level. The compiler variable can be included in a stack of compiler variables, with the stack providing the nesting level of the compiler variable.
In another configuration, the comparing step includes the step of collecting information on a file installed on the target computer during the executing step, with the information including item types contained in the installation data referred to above. The comparing step can further include the step of collecting predetermined information about the target computer. Predetermined information can include a directory of files that were replaced during installation, a directory of files added during the installation, hardware configuration information, and contents of specific text files.
In another configuration, the comparing step generates one or more exceptions (e.g., an event that cannot be handled by a normal process). These exceptions can be, for example, xe2x80x9cfile is missing,xe2x80x9d xe2x80x9cfile is different size,xe2x80x9d xe2x80x9cfile is different date,xe2x80x9d xe2x80x9cfile version is older,xe2x80x9d xe2x80x9cfile version is newer,xe2x80x9d xe2x80x9cfile is not registered,xe2x80x9d xe2x80x9cfile registered is not in the correct installation location,xe2x80x9d registry key is missing,xe2x80x9d xe2x80x9cregistry value name is missing,xe2x80x9d and xe2x80x9cregistry value data is incorrect.xe2x80x9d The exceptions can be filtered to exclude known exceptions from analysis. In this manner, only new exceptions are reported, and the comparing step can be used automatically and/or periodically for system monitoring.
The output of the comparing step can be saved in a format that is suitable for transmission via E-mail. Such saved/E-mailed files can be viewed remotely to display the original comparison data, including color coding to signify the anticipated severity of the exception(s).
In another embodiment of the present invention, a system for generating information for use in verifying an installation of software onto a target computer includes:
(a) means for parsing script of install software to provide a list of items regarding the install software; and
(b) means for collecting information about each item in the list to form installation data.
In another embodiment, a system for generating information for use in verifying an installation of software includes:
(a) a computer;
(b) an install program in the memory of the computer;
(c) a script parser, in the computer memory, for parsing script of an install program to create an installation file. The installation file contains information about a target computer after execution of the install program on the target computer.